European Telecommunications Standard Institute (ETSI) 3rd Generation Partnership Project (3GPP) Technical Specification 23.140 entitled “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Functional description; Stage 2” (a.k.a. ETSI TS 123 140 V6.10.0 (2005-06) and 3GPP TS 23.140 version 6.10.0 Release 6) and 3rd Generation Partnership Project Two (3GPP2) Technical Specification X.P0016-200, “Multimedia Messaging Service; Stage 2 Functional Description” define a non-realtime Multimedia Messaging Service (MMS) which has been widely adopted by network operators (both GSM and CDMA), service providers, and terminal, switch and database manufacturers. The 3GPP2 specification is an adaptation of the 3GPP TS 23.140 technical specification.
FIG. 1 is a schematic representation of a MMS Reference Architecture used in the 3GPP TS 23.140 technical specification. MM1 is a reference point between a MMS User Agent and a MMS Relay/Server. Reference point MM1 is used to submit Multimedia Messages (MMs) from the MMS User Agent to the MMS Relay/Server, to let the MMS User Agent pull MMs from the MMS Relay/Server, to let the MMS Relay/Server push information about MMs to the MMS User Agent as part of an MM notification, and to exchange delivery reports between MMS Relay/Server and MMS User Agents. Reference point MM1 defines the transactions between the MMS User Agent and the MMS Relay/Server. These transactions include notifications of new MMs, retrieval of MMs, forwarding of MMs, and delivery and read-reply reporting. FIG. 2 is a message sequence diagram illustrating exemplary MM1 messages for some of these transactions.
For example, an originator MMS User Agent (UA) submits a terminal-originated MM to an originator MMS Relay/Server using a MM1_submit.REQ MM1 message, which contains MMS control information and the MM content. If a Store information element is present, the MM will also be copied to a MMBox, if the MMBox is supported and enabled for a corresponding subscriber. The MMS Relay/Server responds with an MM1_submit.RES MM1 message, which provides the status of the request. The MM1_submit.RES message unambiguously refers to the corresponding MM1_submit.REQ message. Support for MM1_submit.REQ is optional for the MMS UA, support for MM1_submit.RES is mandatory for the MMS Relay/Server.
Table 1 describes information elements that can be included in a MM1_submit.RES message in accordance with 3GPP TS 23.140.
TABLE 1InformationelementPresenceDescriptionMessage TypeMandatoryIdentifies this message as MM1_submit.RES.Transaction IDMandatoryThe identification of theMM1_submit.REQ/MM1_submit.RES pair.MMS VersionMandatoryIdentifies the version of the interfacesupported by the MMS Relay/Server.Request StatusMandatoryThe status of the MM submit request.Request Status OptionalDescription which qualifies the statusTextof the MM submit request.Message IDConditionalThe identification of the MM if it is accepted by the originator MMS Relay/Server.Store StatusConditionalIf the Store request was present inMM1_submit.REQ, the status of thestore request.Store Status OptionalThe explanatory text corresponding to Textthe Store Status, if present.Stored ConditionalIf the Store request was present inMessageMM1_submit.REQ, the message referenceReferenceto the newly stored MM.
The originator MMS Relay/Server indicates the status of the MM1_submit.REQ in the associated MM1_submit.RES. A reason code given in a Request Status information element of the MM1_submit.RES can be supported with an explanatory text further qualifying the status in an optional Request Status Text information element. If an explanatory text is available in the Request Status Text information element the MMS User Agent should bring it to the user's attention, for example, in the form of a dialogue box (or window) on the display of a terminal hosting the MMS User Agent.
In a typical network operator/service provider implementation the Request Status Text information element is populated with a predetermined fixed message as a function of the Request Status. For example, in the case of a Request Status indicating a successful MM1_submit.REQ the Request Status Text can be set to “Message sent successfully.” The provision of predetermined fixed messages in the Request Status Text as a function of the Request Status represents an incremental operating cost for the network operator/service provider necessitated by compliance with the 3GPP TS 23.140 technical specification.